Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/smtpext/smtpext-minutes-92nov.txt

Text File | 1993-02-17 | 11.1 KB | 270 lines

Editor's Note: Minutes received 12/7/92

CURRENT_MEETING_REPORT_

Reported by John Klensin/MIT

Minutes of the SMTP Extensions Working Group (SMTPEXT)

Summary

The Working Group has once again finished its work and is ready to
submit rewritten documents to IESG for Proposed Standard status.
Documents reviewed and completed this week include revised versions of:


   o ``SMTP Service Extensions'' model
   o ``SMTP Service Extension for Message Size Declaration'' and
   o ``SMTP Service Extension for 8bit-MIMEtransport''.


From a protocol standpoint, these documents are substantially equivalent
to the one that emerged from the Boston IETF except for the changed
keyword model of the ``EHLO'' command response.  The following documents
will follow these three in short order:


   o A contribution to the MIME effort specifying the logic and
     conventions for 8bit to 7bit (transport) conversion,

   o An informational document describing transitional strategies for
     existing ``8 bit clean'' implementations; and

   o An informational document that contains additional clarification
     and guidance material needed to support the protocol extensions
     (most of this material is from the earlier (consolidated) Working
     Group draft.


The Working Group met twice during this IETF. At the beginning of the
first session, the Working Group reviewed new versions of the modular
documents developed after the previous last call.  These versions,
edited by Ned Freed, contained a re-editing to incorporate materials
that were still important from the earlier Working Group draft.
Significant, and other outstanding, technical issues were then reviewed
and decided upon.


   o Document format:  Three+1 (Service extensions, Size, 8bit +
     informational) or three+2 (...  plus informational and folklore
     (e.g., using Julian's document as a basis).
     Decision:  Multidocument model, not one document, but with the
     expectation of advancing the three together, i.e., ``three
     documents, one standard''.


                                   1





o Service extensions/EHLO: The key remaining differences between the
  new proposal and the earlier Working Group one are in the use of
  keywords, rather than specific verbs, in EHLO and in the use of
  parameters (where feasible) to existing commands rather than
  alternate command forms.

  Decision:  The keyword form is clearly preferable.  Given the
  desire to avoid additional round trips, the increase in complexity
  of command parsing associated with the parameters is a desirable
  tradeoff.

o An outstanding question is whether possible future extensions that
  would be associated with commands that don't accept arguments
  should be implemented with new commands or with parameters on the
  old ones.

  Decision:  The present Working Group inclination, reflected in the
  document, is that extensions to parameter-less commands (e.g., DATA
  should be performed by making new commands.  This strategy should
  be slightly more robust against sloppy implementations.  However,
  this decision can be reviewed when the first such extension is
  actually proposed.

o If an extended command is issued with more than one set of
  extension parameters, and the server wishes to indicate that the
  request was not satisfied (i.e., that there is an error condition),
  there could be an ambiguity about which of the parameters (or the
  base command) was at fault.  Several possible solutions have been
  proposed, including using the explanatory text in special ways,
  creating a series of per-extension error codes (possibly in the
  current-unused 6yz or 7yz range), or ignoring the issue on the
  assumption that more detail would encourage attempts to negotiate
  options.

  Decision:  Consistent with tradition and the spirit of RFC1123,
  things either succeed or fail and we do not provide for tricky
  negotiation or alternative-seeking.  A minimum number of reply
  codes will be used, implementors may provide textual explanation,
  but clients should not attempt to take specific action on these.

o SIZE: Change from kilo-octets to bytes, with supporting language.

  Decision:  Agreed without dissent.

o Use of a single number versus several numbers (e.g., the old
  LIMIT).

  Decision:  Agreed.

  These two issues were the only apparently-outstanding ones with
  SIZE and the only substantive differences between the Moore
  proposal and the original committee draft not covered elsewhere in
  this notes.  SIZE is therefore closed out and ready for forwarding.

o 8bit clean:  There was an extended discussion about the existing
  ``8bit clean'' vendors and the supporting facilities they needed.

                                2





  It was concluded that the CONVERT/NOCONVERT facilities did them no
  good and that, if the investment was made to send EHLO, then it was
  plausible to make the further investment to send MIME.

  Decision:  The Working Group agreed, following the pre-July draft,
  that ``8bit'' implies MIME and that the keywords chosen should
  reflect this.  This change removes the NOCONVERT/ CONVERT/ and MIME
  keywords from the EHLO response, and eliminates the need for
  conversion to application/octet-stream and character set
  ``unknown'' in the protocol document.  A separate,
  non-standards-track, document will be developed to suggest
  transition strategies.

o Relaying:  RFC1123 attempted to discourage relaying in the
  Internet.  Sending clients in quest of relays who could perform a
  conversion after receiving a rejection from a target host probably
  represents bad policy (although there is neither need nor desire to
  prohibit static determination of conversion gateways).  Leaving the
  ``go find a relay'' alternative in the text as a means of coping
  with rejections implies error message complexities that are not
  worth the trouble.

  Decision:  Remove the text that appears to encourage finding a
  relay if mail cannot be delivered as originally specified.

o MIME-MIME conversions:  As things now stand, the text contains
  several statements about MIME processing that effectively create
  two-way crossreferences with the MIME document.  The earlier
  Working Group draft resolved this problem by simply insisting that
  any conversions produce valid MIME, believing that the definitions
  of ``valid MIME'' belonged in MIME documents, not in SMTP
  extensions ones.

  Decision:  These text should be removed and replaced by a ``convert
  to valid MIME'' statement.  Any additional statements about MIME
  and how to handle it should be made in modifications to the MIME
  RFC or, if necessary, in non-standards-trace transition document.

o Trace/received syntax:  As of the start of IETF, the document
  overloaded the RFC821/822 Received phrase ``with'' (specified in
  those RFCs as a transport protocol) to include conversion
  statements, e.g., ``with 8bit-to-base64''.  This changed the
  semantics of the 821/822 definition, however subtly.  It also
  produced a significant potential for misunderstanding, as evidenced
  by the example in the text, e.g., Received:  from
  baiji.dbc.mtview.ca.us by dbc.mtview.ca.us with 8bit-to-base64.  It
  is not clear what this means, since the translation/conversion
  would normally occur intra-host.

  Decision:  A new phrase keyword will be added, ``convert'',
  followed by a keyword that will specify the conversion performed in
  the process of receiving mail and sending it on.  This solution
  also reduces the potential for generating many extra Received
  lines, which could be problematic for (probably non-conforming)
  implementations that use the number of Received headers as a trap

                                3





     for mail loops.

   o The conversion issue:  With the proposed documents, the Working
     Group appeared to have come full circle to a variation on the
     so-called ``wretched solution'' of 18 or so months ago.  That
     approach called for expecting that any MTA that was willing to
     accept 8bit traffic must be prepared to convert to 7bit [MIME] if
     needed.  This implied the ability to parse MIME and make
     per-body-part decisions, raising the threshold of effort that must
     go into such an MTA and forcing inclusion of a facility that would
     be unneeded if the transition to an entirely 8bit world ever
     completed.  The Working Group agreed to this in San Diego and did
     not raise it again in Boston, nor was the issue raised during the
     Last Call discussion /cries of agony.  It was, however, suggested
     that there never was real consensus, just exhaustion, and that the
     requirement was ultimately spurious, that the only thing
     accomplished by such a requirement was to insist that an
     implementation that was unwilling to convert lie about the reason
     for rejecting the message.

     Decision:  The document will be revised to indicate a preference
     for conversion, but to provide for message rejection when
     conversion was not possible for some reason.

   o MXE: Some months ago, the Working Group proposed a DNS extension,
     MXE, which could be used to identify enhanced SMTP servers prior to
     opening SMTP connections.  This suggestion was forwarded to the DNS
     Working Group, which has not taken an action on it.

     Decision:  the proposal should be withdrawn.  Given changes in the
     extension model, if anything is needed, it might be based on a
     cross between the EHLO response and the WKS record.  Anyone who is
     convinced that this is important should write a proposal.


The Working Group appears to have reached consensus on the above issues
and the form and content of revised documents.  After the documents are
revised to reflect the decisions outline above and a brief review on the
mailing list, the documents will once again be recommended to the IESG
for processing as a Proposed Standard.

Attendees

Randall Atkinson         [e-mail]
Bryan Beecher            [e-mail]
Fred Bohle               [e-mail]
Kay Chang                [e-mail]
James Conklin            [e-mail]
Chuck Cranor             [e-mail]
Erik Fair                [e-mail]
Roger Fajman             [e-mail]
Ned Freed                [e-mail]
Olafur Gudmundsson       [e-mail]


                                   4





Marco Hernandez          [e-mail]
Russ Hobby               [e-mail]
Tim Howes                [e-mail].
Frank Kastenholz         [e-mail]
Neil Katin               [e-mail]
John Klensin             [e-mail]
Jim Knowles              [e-mail]
Eliot Lear               [e-mail]
Edward Levinson          [e-mail]
Chris Newman             [e-mail]
Michael Patton           [e-mail]
Marshall Rose            [e-mail]
Tim Seaver               [e-mail]
Mark Smith               [e-mail]
Larry Snodgrass          [e-mail]
Einar Stefferud          [e-mail]
Stuart Vance             [e-mail]
Gregory Vaudreuil        [e-mail]



                                   5